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This memo is the second in a series responding to the request that I work with ED to 
develop task plans for the LSI Digital Processor Program to which monies, headcount, 
and Altos have been allocated in 1978 via a transfer agreement for SDD 
responsibility spending in ED. The first memo in the series, reference A, is attached 
for your convenience; it has thus far generated a response from ED in Howard 
Kakita*s memo of 17 May, reference B, in which it is agreed that ED/EDC*s LSI 
Digital Processor Program (1) will begin in June, (2) will produce an LSI DO 
Requirements Specification in September, and (3) will result in detailed task plans for 
SDD review in December. 

Following the interview with Chuck Thacker which led to reference A, I met with 
Butler Lampson to get his ideas. Butler was in general agreement with the contents of 
my previous LSI memo, reference A. In the following, based on my conversation 
with Butler, I attempt to take the next step in resolving a few major strategy 
questions. While Chuck and I and now Butler see eye to eye on many points, I take 
the liberty here to state things only as I see them, not attempting consensus. Perhaps 
some controversy will result this time. Your (written) c o mments are (again) invited. 

Recall that the objective of the subject LSI program is to reduce Star's UMC, that 
UMC reductions will come mainly from lower power and packaging requirements, 
and that significant, if not dominant, UMC contributions come from peripherals . 
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LSI Digital Processor Program, Number Two, Bob Metcalfe, 30 May 1978 

The LSI program's organizational problems must be solved soon. 

With much of the MSI program behind us and painfully remembered, we are all 
anxious to solve the LSI program's organizational problems early. It is true that we 
are all a bit older and wiser and more cooperative, but many stale rivalries persist and 
fresh ones loom. We have technical rivalries among Pare, SDD, ASD, ITG/ED/DPD, 
ED/DPP, ED/SPG, OSD, ITG/PD, and DSD. On one new and especially important 
front, we have ITG/ED's Microelectronics Center in El Segundo and Corporate 
Research's advanced LSI programs in Palo Alto. It is likely that such rivalries and the 
organizational problems they imply will be even more formidable for LSI than they 
were for MSI. 

It is my judgement that the LSI program will fail to meet its objectives if hard 
interfaces are enforced among the organizations formally chartered to handle its 
various pieces. A small and committed team of skilled individuals from the various 
contributing organizations should be formed to design the LSI Star and to direct its 
implementation. LSI Star Team expertise should span Pilot, Mesa, communication, 
peripherals, processor architecture, design automation, and certainly LSI 
microelectronics. This LSI Star Team is similar to that proposed by Henry Samulon 
in reference D, with a change in emphasis intending to soften the interface between 
software, processor architecture, and microelectronics. I propose that I be asked by 
XBS to take on the task of establishing the composition of such a team and 
nominating its five or so members. 

Custom LSI should be launched, but will not reliably meet a 3081 IMO> 

One major strategy question is whether a 3Q81 LSI Star is to be built using custom 
LSI chips from within Xerox or using existing LSI chips from vendors. An example 
of the custom LSI strategy using 10 custom LSI chips of 2 or 3 types is the target LSI 
system sketched in reference A. Two examples of the vendor LSI strategy are 
sketched below. 

It is my judgement (as of 30 May 1978) that the custom LSI strategy will not reliably 
meet a 3Q81 IMO, even when cut back from the lO-chip-type design (used to 
establish issue at IQSl in references C and D) to the 3-chip-type design (sketched in 
reference A)., This difficult judgement hangs on three others: (1) the judgement that 
NSil-2 N-Mos is required for LSI Star and is not sufficiently developed, (2) the 
judgement that our processor architects require knowledge of, but are unfamiliar with 
microelectronics design techniques , and (3) the judgement that advanced LSI system 
design automation s o ftware is required and that we have none, none in ED, none in 
Pare. 1 propose we launch custom LSI, but not depend on it for our LSI Star IMO. 
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LSI Digital Processor Program, Number Two, Bob Metcalfe, 30 May 1978 

A 16-bit vendor LSI microprocessor strategy looks undesirable, 

Butler Lampson and I discussed the possible application of the Intel 8086 16-bit LSI 
microprocessor in building LSI Star for a 3Q81 IMO. The 8086 is judged to be 
among the best in its class. Even so, even without looking at a detailed design, the 
following disadvantages seem to argue strongly against using an 8086 and, therefore, 
against using a 16-bit vendor LSI microprocessor. First, processor and storage 
performance would be low, too low for image processing, too low for multiuser 
configurations, too low even for a single-user LSI Star workstation: something like 
400ns for register-to-register operations and 2000ns for storage references. Second, 
the Mesa system would have to be changed to accommodate the 8086 instruction set 
rather than Mesa bytecodes. This would require a major Mesa and Pilot investment 
This would result in Mesa programs occupying much more main storage because the 
space conservation properties of the bytecodes would be lost. Third, custom 
microcode for performance tuning would be disallowed. Fourth, custom LSI would 
be required for the Xerox Wire. Larry Tesler at Pare has been working with the 8086 
and could serve to elaborate further on this strategy. 
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LSI Digital Processor Program, Number Two, Bob Metcalfe, 30 May 1978 

A bit-slice vendor USI microprocessor strategy looks promising^ 

Butler Lampson was quite prepared to discuss the use of bit-slice vendor LSI 
microprocessors in building LSI Star for a 3Q81 IMO. Butler already has, on a stack 
of yellow sheets, a design using the 100ns AMD 2900. The objective of his design is a 
single-user stellar workstation packaged in its own display housing, like the target LSI 
system sketched in reference A. His workstation would have its own 800,000-bitmap 
display, SA4000 disk, Ethernet (not Xerox Wire yet), and microprocessor bus for 
something like RS232C connections. The controllers for these devices would each 
have a fixed-storage-bandwidth hardware task sharing the microprocessor with the 
fifth. Mesa emulator task. Microcode for all 5 hardware tasks would be held in a 2K 
rom (not ram) containing 40-bit microinstructions. The 2K control rom, 32 64K ram 
chips offering 128K of uncorrected main storage, and controller hardware would 
require an estimated 200 chips (within 20%) on 1 PCBA. The processor would be 
capable of executing short Mesa bytecodes at 1.5 mips. 

Butler explains that there are three major reasons why this vendor LSI bit-slice 
workstation has its desirable combination of characteristics. First, like any new LSI 
design, it uses 64K rams for main storage. Second, by tightly integrating the 10 
controllers and giving them a synchronous share of main storage bandwidth, 
controller chip count is dramatically reduced. For example, he estimates a 20-chip 
Ethernet controller, down from 80 on the Alto. And third, the processor has 
functionality and configurability aimed at the single-user workstation. Unlike the 
MSI DO, there is no 10 bus. There is no shifter; bitblt, however, runs at more than 
twice Alto speed. There is no storage map per se\ the map is held in main storage 
and performance maintained for 80% of bytecode executions via context-switch-time 
mapping of Mesa's L, G, and C registers. 

I asked Butler about how far he is willing to take his design; he is willing to have it 
taken now as it sits on yellow sheets. I propose that we ask the aforementioned LSI 
Star Team to study Butler*s vendor LSI bit-slice design along with Chuck Thacker*s 
custom LSI 3-chip-type design. It is my judgement that the bit-slice design holds the 
greater promise for the short term, IMO 3Q81, and the custom LSI for the long term. 
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